1. Field of the Invention
The present invention relates generally to assembler language instructions that declare external symbols as definitions and references and, in particular, to the association of descriptive information with instructions that define and reference external symbols for use in determining whether a definition of and a reference to an external symbol are compatible.
2. Description of the Related Art
Programmers write computer programs in languages such as assembler language, COBOL, FORTRAN, C, C++, etc. A group of statements written in such a language is referred to as a source module. Before the source module can be executed, the source statements within the source module must be transformed to machine readable executable code.
An assembler or compiler, referred to herein as a source translator, translates the source module into an object module, which includes machine readable executable code, data, external symbols, address constants, and further bookkeeping information used in the process of transforming the object module into an executable file. A linkage editor combines one more object modules into a load module in preparation for execution. Typically, the object modules being combined by the linkage editor contain a single definition of an external symbol, and one or more references to the symbol. If one object module includes a reference to an external symbol defined in another object module, then the linkage editor may resolve this reference to the definition in the load module.
Often, the source translator disregards descriptive information about external symbols included in the source module when generating the object module, typically because there is no mechanism for including such descriptive information in the object module. As a result, object modules and load modules often include little or no information on the attributes of external symbols. Furthermore, in the prior art, assembler language instructions, such as the ENTRY, CSECT, EXTRN, and DC instructions in the IBM assembler language, did not include descriptive information about the attributes of the symbols used as operands in the assembler language instructions. These and other specific aspects of assembler language discussed herein are described in the publication xe2x80x9cHigh Level Assembler for MVS and VM and VSE, Language Reference,xe2x80x9d Release 3, Document Number SC26-4940-02, IBM Corporation, which publication is incorporated by reference herein in its entirety.
Generally, the source module and object module include one or more control sections. A control section is the smallest subdivision of a program that can be relocated as a unit. At coding time, the programmer creates control sections in the source modules, establishes the addressability of each control section, and establishes symbolic linkages between control sections that lie in different source modules. The programmer establishes symbolic linkages by declaring an external symbol in one source module to reference a control section or an entry point defined within another object module. Source modules external to a module in which an external symbol is defined can reference the text at the location identified by the external symbol. In this way, the external symbol is the vehicle used for establishing symbolic linkages between programs.
In the IBM assembler language, the programmer can use the ENTRY, CSECT, COM, DXD, RSECT, and START instructions to define external symbols in the source module. The ENTRY instruction defines the external symbol as the location where the the symbol named in the ENTRY instruction is placed. For instance, the instruction ENTRY B declares the external symbol B as the point within the control section where the symbol B is defined.
The CSECT instruction identifies a control section name as an external symbol. For instance, the instruction B CSECT names the control section B, thereby allowing external source modules to reference the control section identified by the external symbol B. The programmer can declare external symbols in a source module that are not defined in that module using the EXTRN instruction. A declared symbol can be used in instruction operands within that source module. For instance, the instruction EXTRN C declares that the external symbol C will be defined in a different source module, and may be referenced from the source module containing the EXTRN instruction.
Symbols can have two types of attributes, inherent (or implicit or intrinsic) and extended (descriptive). Inherent attributes are attributes that are typically part of a fixed set of properties associated with an external symbol. Examples of inherent attributes of a symbol include: addressing mode (AMODE, which implicitly designates the symbol as naming executable code); and residency mode (RMODE, which implicitly designates a region of storage where the object named by the symbol must reside). Descriptive or extended attributes are additional information either derived from the program""s language statements or provided by other means. Examples of descriptive attributes include: whether an external symbol reference is to data (and what data types and structures) or to executable code (and what numbers and types of arguments are being passed); whether an external symbol definition is for data (and what data types and structures) or for executable code (and what expected number and types of arguments are to be received).
One of the shortcomings of current methods for using external symbols is that the instructions identifying the symbols do not retain attribute information on the declaration of the symbols, nor do they provide any means for declaring additional attributes. This lack of information makes it difficult for the programmer to debug incompatibility errors that arise if an instruction referencing the symbol (such as EXTRN) is incompatible with an instruction defining that symbol (such as ENTRY or CSECT).
For example, if the external symbol is defined as a location naming code, but the reference to the symbol expects data, then an incompatibility error may arise. An incompatibility error may also arise if the reference is compatible with only 24-bit addressing and the symbol is defined as using only 31-bit addressing. These incompatibility errors could prevent the program from properly executing.
Thus, there is a need in the art for techniques for associating descriptive information with symbols that can be used during binding to check the compatibility of references to symbols.
The present invention is directed to a method, system, and information bearing medium for associating attribute information with symbols. A command is processed associating user specified attribute information with a symbol definition or reference. The user specified attribute information is added to an object file including the symbol definition or reference. The attribute information may then be used to determine compatibility of the symbol when resolving references to the symbol.
In further embodiments, the user specified attribute information is associated with an address constant.
The attribute information may indicate attributes including linkage, scope, direct or indirect reference, conformance level, association of code and data areas, as well as user specified extended information.
Preferred embodiments provide a technique for assigning attribute information to a symbol that may be maintained with the symbol in the object file and used for compatibility checking purposes to provide the programmer a greater definition of compatibility and control. Providing a greater degree of compatibility at different user specified levels increases the types of fixes and patches that may be provided to correct incompatibility errors because the extended attribute information may be used to diagnose the source of the incompatibility at a finer level of detail and then determine the appropriate correction operation that specifically addresses the compatibility problem.